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REMARKS/ARGUMENTS 

Claims 1-70 are pending in this application. Claims 1, 19, 34, 38, 45, 53, 59 are currently 
amended, and such amendments are fully supported by the specification and drawings, at least at 
page 17, lines 14-31, and Figure 6. For at least the reasons set forth below, Applicants assert that 
all claims are in condition for allowance. 

Applicants thank the Examiner for the telephonic interview of 9/6/2005 and the follow-up 
telephonic interview of 9/7/2005, wherein the present application and Application Serial No. 
09/783,673 were discussed. In the interview of 9/6/2005, Applicants' representative discussed 
the Simonoff reference with Examiner. It appeared that Applicants' argument regarding the non- 
anticipation of the claims by the Simonoff reference were persuasive to Examiner, particularly 
the argument that the reference failed to teach the recited component, "skeletal UI". However, 
on 9/7/2005 Examiner contacted Applicants' representative again and provided a new reference, 
U.S. Patent No. 5,347,632 (the "Filepp" reference), which Examiner asserted teaches the 
"skeletal UI." 

Double Patenting Rejection 

Claims 1-3, 5-6, 10-18, 46-47, 19-20, 29-31, 33-34, 36, 38, 45 are rejected under the 
judicially created doctrine of obviousness-type double patenting as being unpatentable over 
claims 1-53 of U.S. Patent Application No. 09/783,673 in view of Simonoff et al., U.S. Pat. No. 
6,078,322. A terminal disclaimer in compliance with 37 C.F.R. § 1.321(c) is filed herewith to 
overcome the nonstatutory double patenting rejection, thereby obviating this rejection. 

Rejection under 35 U.S.C. $102 

Claims 1-5, 9-11, 12, 13-17, 19-23, 27-28, 29, 30-64, 65-70 were rejected under 35 
U.S.C. § 102(e) as being anticipated by Simonoff et al. U.S. 6,078,322. As set forth in more 
detail in the previous amendment and during the aforementioned telephonic interviews, the 
reference fails to describe every element of every claim as required by MPEP § 2131, and 
therefore the rejection is unsupported by the art. To the extent Examiner was not persuaded 
during the interviews that Simonoff failed to anticipate the pending claims, Applicants address 
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the Simonoff reference below and Applicants have amended the claims to clarify the "skeletal 
UI" as requested by examiner. To the extent that Examiner was convinced that the Simonoff 
reference does not teach at least the "skeletal UI" but believes the Filepp reference teaches this 
limitation, the Filepp reference is also addressed below. For at least the reasons stated below, 
Applicants respectfully request that the rejection be withdrawn. 

Simonoff Reference 

Independent claims 1, 38, and 53 and dependent claims 66, 68, and 70 recite 
"supplementing a skeletal UI. . .with one or more icons, labels or menu items, or combinations 
thereof." The Simonoff reference fails to disclose this limitation. Simonoff describes a Universal 
Client device that is downloaded to the client host 300, which in turn loads and interprets a 
GUIScript file, and then displays an appropriate GUI to the user. Col. 8, line 66-Col. 9, line 4; 
Col. 9, lines 34-38. However, there is no indication in the reference that the GUIScript file or the 
GUI is anything less than an entire UI displayed to a user. Nowhere does Simonoff describe a 
"skeletal UI," much less supplementing a "skeletal UI" with icons, labels, or menu items as 
claimed. Because the reference does not teach or suggest a skeletal UI as claimed, the rejection 
fails to establish a valid § 102 rejection, which requires that a reference teach every element of 
every claim . See MPEP § 2131. 

In response, Examiner argued: 

...Simonoff teaches the above limitations. See for example, Col. 
12, lines 24-60, wherein the GUIScripts carries a GUI change in 
response to an event, the event, i.e. button clicking, has resulted in 
partial GUI updating, only a portion of the GUI are generated at a 
time, any additional changes applies to the existing GUI are based 
upon system events, thus, GUI elements are supplemented in 
accordance with client requests, (see also, Col. 11, lines 55-67; 
Col. 12, lines 40-45). 

Office Action, 6/17/2005, p. 26-27, f 72. However, as explained by Applicants' representative 
in the telephonic interview of 9/6/2005, this teaching of Simonoff does not anticipate the 
"skeletal UI." Specifically, the operating steps of the system of Simonoff cited by Examiner and 
described at Col. 12, lines 24-60 and Fig. 5, describe changing a GUI by indiscriminately 
refreshing the entire GUI based on a GUIScript message. See Col. 12, lines 49-53 ("The second 
GUIScript message is. . .used by the Universal Client device in generating a refreshed GUI 
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during step 14"); see also, Fig. 5, step 14 ("refresh GUI"). There is no indication that any 
component or element described in Simonoff is skeletal, and there is no indication that such a 
component or element is supplemented much less that is supplemented " with one or more icons, 
labels or menu items " as claimed. 

Moreover, Examiner's argument rests on the assumption that when an application in the 
Simonoff system performs an operation, "GUIScripts carries a GUI change" and "only a portion 
of the GUI are generated at a time." However, Simonoff describes only that an application 
message may include "information denoting a change in the appearance of the GUI displayed on 
the client host 300." Col. 12, lines 40-45. Interpreting this passage as teaching that the 
GUIScript message contains only changes to the GUI definition — rather than an entire GUI 
definition with changes — is contrary to the reference as a whole, which teaches that the 
GUIScript file "defines all the display windows and their operation for the application running 
on the application host 200" and is usable to "display the appropriate GUI to the user." Col. 9, 
lines 33-50. See MPEP § 2141.03 (VI)("A prior art reference must be considered in its entirety, 
i.e., as a whole, including portions that would lead away from the claimed invention .") 

Additionally, Examiner's argument is further made moot by the amendments to the 
independent claims, which inter alia clarify the "skeletal UI" as requested by Examiner during 
the interview. Specifically, claims 1, 38, and 53 now recite that "the skeletal UI specifies a 
layout of the client-resident intermediate UI including respective locations of the one or more 
icons, labels or menu items, or combinations thereof," and claims 19, 45, and 59 recite that "the 
UI form [definition] includes a list of controls and respective locations of the controls as 
rendered on the client device, the controls being UI objects provided by the client device 
operating system or other client-resident application." Claims 1, 38, and 53 further recite "the 
skeletal UI and the one or more icons, labels, and menu items being independently updateable 
from one another," and claims 19, 45, and 59 recite "the UI form definition and the controls 
being independently updateable from one another." Simonoff clearly fails to teach any skeletal 
UI or form element that achieves all of these limitations. 

For at least these reasons, the Simonoff reference does not describe such GUI objects as 
being skeletal nor supplementing the same. 
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Filepp Reference 

During the interview on 9/7/2005, Examiner identified the Filepp reference, U.S. Patent 
No. 5,347,632. It was not specified precisely how this reference was to be applied (e.g., part of a 
35 U.S.C. § 102 or 35 U.S.C. § 103 rejection), but this reference neither teaches all of the recited 
claim limitations nor is it properly combinable with the Simonoff reference. 

With respect to combinability, Filepp may not properly be combined to anticipate the 
claims because the reference teaches away from the operation of the present claimed invention. 
See MPEP § 2145 ("A prior art reference that 'teaches away 5 from the claimed invention is a 
significant factor to be considered in determining obviousness. . .") Specifically, the present 
invention is directed towards a thin client architecture, where substantial proportions of the 
processing are performed server-side to reduce the load on the client . See claims 1, 19, 38, 45, 
53, and 59; see, also, Spec. p. 6, lines 19-21 ("A preferred embodiment of the present invention 
provides a data communication architecture that exhibits the following attributes: a relatively 
thin client for reduced client-side resource demands . . .") (emphasis added) In stark contrast, 
Filepp is directed towards an architecture that reduces the load on the server and provides for a 
fat client: 

...the invention includes procedures for formulating objects that 
have been specially structured to include display data, control data 
and program instructions for supporting the applications at the 
network reception systems, the objects being pre-created, parceled 
units of information that may be distributed and stored at lower 
levels in the network ... so as to reduce processing demand on the 
network higher element . . . 

Col. 2, line 60-Col. 3, line 1 (emphasis added); see, also Col. 76, lines 37-47 ("the table can be 

presented to the user's RS 400, where the [client-side] RS 400 can provide the data processing 

required to present the potentially relevant keywords, objects and associated applications to the 

user. . . this procedure reduces demand on server . . ."); see, also Col. 1, lines 16-25 ("This 

invention relates generally to a distributed processing. . .computer network in which the 

interactive text/graphic sessions are comprised of pre-created blocks of data and program 

instructions which may be distributed downwardly in the network for use at a software enhanced 

user computer terminal that reduces processing demand on the higher-level network 

elements ..."); see, also Col. 75, lines 41-56 ("the method aspect of the invention includes an 
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improved procedure for searching and retrieving applications from the store of applications 
distributed throughout network. . . this reduces the demand on the server . . ."). 

Accordingly, considering the Filepp reference "in its entirety, i.e., as a whole , including 
portions that would lead away from the claimed invention," one skilled in the art would not 
reasonably combine Filepp with Simonoff, or any other reference, to teach or suggest the 
limitations of the present claimed invention. MPEP § 2141.03 (VI). Moreover, the teachings of 
Filepp may not be considered in a vacuum with improper hindsight reasoning; as the Federal 
Circuit noted: 

It is impermissible within the framework of section 103 to pick and 
choose from any one reference only so much of it as will support a 
given position, to the exclusion of other parts necessary to the full 
appreciation of what such reference fairly suggests to one of 
ordinary skill in the art. 

In re Hedges, 783 F.2d 1038, 1041, 228 U.S.P.Q. 685, 687 (Fed.Cir.1986). For at least this 

reason, Filepp is not properly combinable to create a valid 35 U.S.C. § 103 rejection. 

In addition, the Filepp reference fails to disclose every claim limitation, and in particular 
the reference fails to teach or suggest at least the "skeletal UI" limitation. For example, 
independent claims 1,38, and 53 and dependent claims 66, 68, and 70 recite generating or 
displaying a user interface "including the step of supplementing a skeletal UI. . .with one or more 
icons, labels or menu items, or combinations thereof." In contrast, Filepp does not "supplement" 
a skeletal UI, but rather the architecture of Filepp formulates "objects that have been specially 
structured to include display data, control data and program instructions for supporting the 
applications at the network reception systems, the objects being pre-created, parceled units of 
information that may be distributed and stored at lower levels in the network; e.g., at the [client- 
side] reception system." Col. 2, lines 60-68. In other words, the displays of Filepp are defined 
by pre-created , predefined objects that already include display data, control data, and program 
instructions. The plan views shown in Figures 3a and 3b show page partitions (Fig. 3a) and 
display fields (Fig. 3b), but these are not "icons, labels, or menu items" as claimed. Nowhere 
does Filepp describe these objects being created by supplementing a skeletal UI. 
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Moreover, the architecture and operation of Filepp fail to teach other claim limitations 
and generally teach away from the present invention for a variety of additional reasons. Because 
Applicants have not yet been provided a with reasoned rejection incorporating the Filepp 
reference, a sampling of these additional shortcomings of the reference are provided here. For 
example, independent claims 19 and 45, and dependent claims 2, 54 and 60, recite defining or 
generating a user interface form based upon or in response to a number of device capabilities for 
a client device, and independent claims 19, 45, 59 recite "the controls being UI objects provided 
by the client device operating system or other client-resident application ." Filepp fails to teach 
this limitation, and instead discloses display objects that contain "information about what is to be 
displayed and how it is to be displayed," but nowhere does the reference teach or suggest that 
these objects are "based upon" or "in response to" client device capabilities or provided by the 
client device OS or applications as claimed. See, e.g., Col. 7, lines 24-46 and Col. 7, line 64-Col. 
8, line 39 (describing the objects of Filepp without any indication of correspondence to client 
device capabilities). Independent claims 1, 45, 53, and 59 of the present invention also recite 
populating or rendering a native UI control of the UI on the client device with data items, and 
dependent claim 34 recites defining a UI form for a client device, including at least one native 
control that is stored locally at the client device. Filepp also fails to teach these limitations, and 
instead discloses pre-created objects with display data that are sent to the client device, not native 
objects as claimed. Col. 2, lines 60-68. 

For at least these reasons, the Filepp reference neither teaches all of the recited claim 
limitations nor is it properly combinable with the Simonoff reference. 

Rejection under 35 U.S.C. § 103 

Claim 18 was rejected under 35 U.S.C. § 103(a) as being unpatentable over Simonoff in 
view of 'Official Notice'. Neither Simonoff nor the Official Notice, nor the combination thereof, 
teach or suggest all of the limitations of claim 18. Claim 18 is allowable as being dependent 
from claim 1 for the reasons set forth above. 

Claims 6-8 and 24-26 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Simonoff et al. US 6,078,322 in view of "Browser wars: Rest in peace," Patrick, January 2001. 
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Included with this response is a 37 CFR § 1.131 declaration, swearing back of the Patrick 
reference. This declaration is seasonably presented in accordance with MPEP § 715.09 and 
effectively antedates the Patrick reference in accordance with MPEP § 715. Thus, the 35 U.S.C. 
§103 rejection is now moot. 

This application now stands in allowable form and reconsideration and allowance are 
respectfully requested. 



Respectfully submitted, 



DORSEY & WHITNEY LLP 
Customer Number 25763 





Christopher R. Hilberg, 
(612) 492-6694 
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